The term Service-Oriented Architecture (SOA) generally refers to a software strategy that separates functions from enterprise applications into interoperable, standards-based services, which then may be combined with other services and reused to meet particular business needs. Accordingly, by employing SOA, functionality provided by applications (from potentially multiple vendors) can be “exposed” as one or more services, and then “orchestrated” (e.g., using orchestration capabilities like Business Process Execution Language (BPEL)) into new composite applications. These composite applications may be developed to support an organization's business processes.
Service Component Architecture (SCA) is a software technology created by major software vendors, including IBM, Oracle, and TIBCO. SCA describes a model for building applications and systems using SOA principles, and further builds on open standards, such as Web services, to extend and complement existing SOA approaches.
A basic aspect of SCA is a composite, which is a unit of deployment and provides services that can be accessed remotely. A composite is made up of one or more components, each of which can be directed to performing a particular task or set of tasks. Components may offer their function as “services,” and either may be used by other components within the same module (e.g., composite) or may be made available for use outside the module through entry points. Components may depend on services provided by other components—either local or remote—and these dependencies may be referred to as references. References either may be linked to services provided by other components in the same composite, or references can be linked to services provided outside the composite, which potentially can be provided by other composite. Also included within a composite are linkages between references and services, which are referred to as wires.
SOA applications can also utilize bindings (or “adapters”), which refer to the communication protocols used between modules in the system. Accordingly, one or more bindings can be assigned to a single reference, each enabling communication over a different type of protocol.
Over time, software complexity continues to rise and thus, SOA applications similarly increase in complexity. For example, an application may include many composites interacting with each other and other external systems, and each composite may include multiple components. Moreover, with the increased adoption of cloud-services, many such SOA applications may be deployed using a common set of computing resources.
With this increased complexity, it may become difficult to manage these applications. For example, when the performance of the application is negatively impacted, it can be tremendously difficult to identify which, if any, of the portions of a large SOA application are responsible for the performance degradation, and moreover, why those portions are not being performant. Further, when these performance degradations (or failures) occur, it is difficult to prevent the failures from impacting other system resources, prevent in-flight data from being lost, and efficiently recover from such system failures.
Accordingly, there is a tremendous need for better detection of, response to, and recovery from faults occurring in complex SOA systems.